home *** CD-ROM | disk | FTP | other *** search
/ Ian & Stuart's Australian Mac: Not for Sale / Another.not.for.sale (Australia).iso / fade into you / getting there / News / UUPC 3.1b25 / Documentation / Modems and cables < prev    next >
Text File  |  1991-11-03  |  11KB  |  200 lines
  1. uupc establishes connections with other sites by use of what is known as 
  2. a "chat script".  A script of this sort consists of a set of "expect" 
  3. strings (what uupc expects to "hear") and a set of "send" strings (what 
  4. uupc will send when it "hears" what it expects).  Chat scripts can have 
  5. some small amount of "intelligence", in the sense that an "expect" string 
  6. can specify some actions to be taken if the expected string is _not_ 
  7. received within a reasonable amount of time.  It isn't possible to built 
  8. any very sophisticated scripts within uupc, however... loops and 
  9. branching within scripts is not possible.
  10.  
  11. uupc is most easily used with a Hayes-compatible modem.  With modems of 
  12. this sort, you can use the built-in "HAYES" dialer to place calls to your 
  13. neighbor sites.  The HAYES dialer is flexible enough to work with most 
  14. modems which support extensions to the Hayes command set... you can 
  15. include additional commands, options, and S-register settings in the chat 
  16. script, and the HAYES dialer will add them to the commands it sends to 
  17. the modem.
  18.  
  19. If you have a non-Hayes-compatible modem, you won't be 
  20. able to autodial... instead, you'll have to write up a complete chat 
  21. script to send dialing commands to the modem and handle the modem's 
  22. responses.
  23.  
  24. You should set up the modem's DIP switches, S-registers, and/or other 
  25. options or nonvolatile memory so that the modem will behave in the 
  26. following fashion:
  27.  
  28. -  The modem should be configured to "watch DTR" or "honor DTR"... that 
  29. is, it should pay attention to the Data Terminal Ready signal from the 
  30. Macintosh.  uupc raises (asserts, turns on) DTR when it wishes to place a 
  31. call or is willing to accept an incoming call.  uupc lowers (deasserts, 
  32. turns off) DTR to signal that it has completed a call, and wishes the 
  33. modem to "hang up the phone".
  34.  
  35. Many Hayes-compatible modems are delivered with a different default 
  36. setup... "provide DTR" or "ignore DTR".  Modems which are set up in this 
  37. fashion will not hang up the phone when DTR is deasserted;  this will 
  38. cause uupc to become confused, or to fail to terminate calls reliably.
  39.  
  40. Some Hayes-compatible modems can be set up so that deasserting DTR not 
  41. only hangs up the phone, but also resets the modem to its default 
  42. condition.  If your modem supports this option, I recommend that you use 
  43. it... either by storing this option in the modem's nonvolatile memory 
  44. (best) or by including the command needed to activate this mode in the 
  45. HAYES dialer specification.
  46.  
  47. -  The modem should be connected to the Macintosh with a standard 
  48. "Macintosh to modem" peripheral cable.  You should NOT use a "hardware 
  49. handshaking" cable, which connects the Mac's handshaking pins to the RTS 
  50. and CTS lines on the modem... these cables do not allow uupc to control 
  51. the DTR line, and the modem won't work properly (it either won't go 
  52. off-hook and dial, or won't hang up when you expect it to).
  53.  
  54. -  The modem should be set up with the "auto-answer" feature disabled.  
  55. This is usually done via a DIP switch, or by setting the S0 register to 
  56. zero.  uupc will enable auto-answering when it's ready to accept an 
  57. incoming call.
  58.  
  59. --------
  60.  
  61. FLOW CONTROL, COMPRESSION, AND PROTOCOLS
  62.  
  63. Many modern Hayes-compatible modems support one or more of the following:
  64.  
  65. -  Error control... MNP levels 3 or 4, or V.42.  When both modems in a 
  66. conversation support a particular error-control protocol, and when the 
  67. protocol is enabled, the modems will provide a nearly-error-free 
  68. communication link even if the phone line is somewhat noisy... data is 
  69. checked for correctness, and retransmitted one or more times if it's 
  70. incorrect.
  71.  
  72. -  Compression... MNP level 5, or V.42bis.  Modems which support 
  73. compression will "squeeze" data into a smaller form, using a 
  74. sophisticated "lossless" compression algorithm such as Huffman or 
  75. Lempel-Ziv coding.  Some data (ASCII text) can be compressed by as much 
  76. as 4:1;  other data (.SIT files) cannot be compressed by any significant 
  77. amount.
  78.  
  79. - Flow control. Error-controlling and data-compressing modems are usually
  80. capable of accepting data from a computer (or a human) faster than it can
  81. be sent over the phone line, and storing the data for transmission at the
  82. earliest possible moment. Modems of this sort can usually signal the
  83. computer that their storage capacity is running out, and that additional
  84. data should not be sent until some of the older data has been successfully
  85. transmitted. Two forms of flow control are commonly used: XON/XOFF or
  86. "software" flow control, in which special ASCII characters are used to
  87. indicate "stop sending" and "OK, go ahead", and RTS/CTS or "hardware" flow
  88. control, in which electrical signals on the serial-port connector are used
  89. to control data transmission).
  90.  
  91. In order for uupc to work properly, you _must_ configure your modem for 
  92. the correct sort of error control, compression, and flow control.  The 
  93. wrong settings can prevent uupc from working at all, or can greatly 
  94. reduce the throughput of a uupc connection.
  95.  
  96. You may want to store these configuration settings in your modem's 
  97. nonvolatile memory.  More commonly, you'll want to include the necessary 
  98. commands in your chat script... append them to the HAYES dialer 
  99. specification (e.g. "HAYES+commands" or "HAYES!commands").
  100.  
  101. RULES OF THUMB FOR THE 'g' PROTOCOL
  102.  
  103. For the normal 3-window 'g' protocol: turn all flow control OFF! This is
  104. CRITICAL! The 'g' protocol is self-pacing, and does not require either
  105. hardware or software flow control.
  106.  
  107. The 'g' protocol insists on being able to send all 256 ASCII data codes,
  108. without interpretation or interference by the modem. If XON/XOFF flow
  109. control is in use at _any_ point in the communication path between uupc and
  110. its peer, the protocol will eventually stall and will not recover. Hardware
  111. (RTS/CTS) flow control cannot be used with a standard Mac-to-modem serial
  112. cable... it requires a "hardware handshaking" cable, which (as noted above)
  113. is _not_ recommended for use with uupc.
  114.  
  115. For most 'g' protocol sessions, turn error control and data compression 
  116. off.  Error control adds delay to most transmissions, and this will cause 
  117. the 'g' protocol to run more slowly than otherwise possible.
  118.  
  119.   [Possible exception:  if your peer site supports a 'g' protocol window 
  120.    of more than 3 packets, and if your files are long enough to require 
  121.    more than a few seconds each to transmit, try turning error control and 
  122.    data compression on, if your modems support them.  You may get better 
  123.    throughput.  You'll have to increase the port speed... for example, if 
  124.    you're placing a call at 2400 bits/second, use a speed setting of 4800 
  125.    or 9600 in your chat script... and call the dialer "HAYES!" rather than
  126.    "HAYES" so that it will lock the serial port at the higher speed.  Specify
  127.    'g7' in the protocol field, to enable a larger window.]
  128.    
  129. RULES OF THUMB FOR THE 'f' PROTOCOL
  130.  
  131. The 'f' protocol is a very different beast.  It REQUIRES that the modems 
  132. support error control and flow control... and it works very 
  133. well indeed with modems which support data compression, and which are 
  134. operating at a high serial-port speed.  I've used 'f' with both the
  135. MNP 3/4 error control protocol (with its attendant MNP 5 data compression
  136. capability) and the newer V.42 error control protocol (with V.42bis
  137. compression).  If your modem supports either of these protocol suites, and
  138. if the system you're calling has a compatible error-control modem and is
  139. capable of using the 'f' protocol, you may want to give it a try.
  140.  
  141. The 'f' protocol implementation in uupc 3.0 is designed to work with the
  142. same type of serial cable as the 'g' protocol uses... that is, the cable is
  143. not required to support hardware flow-control handshaking.  When uupc starts
  144. up an 'f' protocol session, it configures the Mac's serial ports for
  145. XON/XOFF flow control, which works quite well with 'f' (although it's slow
  146. death if you try to use it with 'g').  Naturally, this requires that the
  147. modem be capable of supporting XON/XOFF flow control (almost all error-
  148. controlled modems do) and that the modem be configured to actually use
  149. XON/XOFF flow control.
  150.  
  151. The best way to set the modem configuration is to tell the HAYES dialer how
  152. to do so.  This is done by invoking the dialer as "HAYES+options" or as
  153. "HAYES!options", rather than simply as "HAYES".  The "options" would be the
  154. necessary S-register settings, or other modem command codes needed to
  155. turn on XON/XOFF flow control.  For example, on a U.S.Robotics Dual Standard
  156. modem, an appropriate dialer specification would be
  157.  
  158.    barney Any a HAYES!&B1&M4&H2&I2 19200 5551212 f ogin: me word: again
  159.  
  160. This means
  161.  
  162. -  Use the Hayes-compatible-modem dialer;
  163. -  Send commands to the modem port (a) at 19200 bits/second.
  164. -  Do not change the Mac's serial port speed to match the CONNECT message (!);
  165. -  The modem should not change its serial-port speed to match the speed of
  166.    the actual connection, but should continue to operate at the speed at
  167.    which the dialing command was sent (&B1);
  168. -  The modem should insist upon an error-controlled session, and should
  169.    disconnect if it cannot negotiate error control with its peer (&M4);
  170. -  The modem should use XON/XOFF flow control when accepting data from
  171.    the Mac (&H2) and when sending data to the Mac (&I2);
  172. -  Use the 'f' protocol (f).
  173.  
  174. If your modem supports data compression, you'll get the best throughput if
  175. you use the highest serial-port speed that your modem supports (e.g. 19200
  176. bits/second or faster for a V.32 modem), and instruct both the modem and
  177. the Macintosh to lock their serial ports at the higher speed regardless of
  178. the actual modulation speed of the session (e.g. 9600 bits/second for a
  179. V.32 connection).
  180.  
  181. It's important to remember that the 'f' protocol requires flow control at
  182. both ends of the connection.  You'll have to make sure that the system
  183. you're calling, and the modem that it uses, are capable of supporting
  184. flow control, and have been configured to do so.
  185.  
  186. If you're calling another Macintosh running uupc, flow control should be
  187. specified in the dialer field for the INCOMING entry on the system which
  188. is receiving the phone call (very much as was done above, in the entry for
  189. "barney").
  190.  
  191. If you're calling a Unix system, you should ask the system administrator to
  192. make certain that the port you're calling is configured for flow control.
  193. Hardware flow control (RTS/CTS) is usually most appropriate for Unix
  194. systems.  This usually requires that the modem be pre-programmed for this
  195. form of flow control (the necessary options being placed in the modem's
  196. nonvolatile memory), and that the Unix "login" or "getty" program
  197. enable hardware flow control for the serial port (via options in the
  198. /etc/ttytab or /etc/gettytab file, or equivalent).
  199.  
  200.